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LONG-TERM  GOAL 

The  general  objective  is  to  investigate  basic  and  applied  problems  associated  with  the  efficacious 
reconnaissance  of  littoral  waters  in  support  of  mine  warfare  and  oceanographic  tasks. 

OBJECTIVES 

This  proposal  addresses  several  control  system  software  development  tasks  necessary  to  the 
achievement  of  more  robust  and  optimized  single  and  multiple  vehicle  mine  reconnaissance 
capabilities.  In  particular,  this  proposal  will  focus  on  multiple  vehicle  co-ordination  and  control 
including  the  infra- structure  for  more  sophisticated  mission  plans.  Part  of  this  infra- structure  is  the 
new  hierarchical  state  machine  based  on  high  level  control  software.  Another  key  part  of  this  infra¬ 
structure  is  multiple  vehicle  hardware  in  the  loop  simulation.  The  idea  is  to  extend  the  current 
hardware  in  the  loop  simulation  to  include  better  multiple  vehicle  capability  so  that  we  might  simulate 
the  logic  of  multiple  vehicle  missions  including  communications  to  reduce  at-sea  testing  costs. 

APPROACH 

High  Level  Control 

The  term  Convenient  Hierarchical  Autonomous  State  Machine  is  used  to  describe  a  single  hierarchical 
state  machine  (in  which  states  are  hierarchically  organized)  with  additional  features.  Each  CHASM 
represents  a  particular  kind  of  high-level  controller  that  is  assigned  a  given  task  (for  example  the 
control  of  the  speed,  or  the  depth  of  the  AUV).  CHASM’s  are  built  dynamically  from  some  text 
streams.  Each  CHASM  is  under  the  responsibility  of  a  manager,  which  runs  it  on  a  cyclic  basis.  Each 
manager  runs  a  separate  process  and  Inter-Process  Communication  (IPC)  is  done  through  a  dynamic 
shared  memory  (SM)  (see  figure).  In  particular,  the  Navigator  manager  has  to  be  entirely  rewritten  as  a 
CHASM  created  from  a  mission  plan  whose  syntax  remains  accessible  to  the  non-expert  users. 

Each  state  of  a  CHASM  represents  a  mode  of  the  system  and  is  associated  with  some  actions  (or 
behaviors)  that  are  components  that  have  to  be  fired.  We  transit  from  state  to  state  based  on  the 
progression  of  the  AUV.  The  CHASM  framework  is  therefore  made  of  generic  components,  i.e. 
components  that  are  both  hardware  and  application  independent.  Behaviors  are  application  dependent 
but  can  be  configured  for  different  types  of  hardware.  The  CHASM  framework  supports  the  plug  in  of 
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reusable  behavior  objects  that  could  implement  different  portions  of  the  command  and  control  logic 
(i.e.  the  plug-in  of  new  components  that  can  be  triggered  by  the  CHASM). 

Instead  of  developing  a  solution  with  built-in  behaviors,  some  work  has  to  be  done  to  provide  a 
solution  that  offers  a  modular  design  to  add,  remove  or  modify  control  features.  A  modular  solution 
can  be  assimilated  to  what  is  commonly  called  ‘plug-in’ .  That  is,  modules  that  can  be  easily  inserted 
into  an  application  to  offer  new  features.  The  design  of  the  architecture  was  developed  so  that  new 
functionalities  can  be  added  and  included  into  the  software  without  modifying  the  code  or  recompiling 
it.  There  is  no  need  to  stop  the  mission  and  the  software  to  update  or  add  a  new  behavior.  There  isn't 
additional  installation  in  order  to  use  the  plug-ins  that  can  be  downloaded  through  RF  and  initialized 
automatically  by  the  software  if  they  are  used  in  the  mission  plan  for  a  CHASM  manager  (i.e.  only 
when  needed).  Developers  only  need  to  know  how  to  design  a  new  behavior  -  a  new  plug-in  -  to  extend 
the  application  without  knowing  any  deep  details  about  the  CHASM  architecture. 
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Figure  1:  Communication  Model  of  the  Morpheus  AUV: 
Each  manager  is  implemented  as  a  Convenient  Hierarchical 
Autonomous  State  Machine  ( CHASM) 


Simulation 

One  of  the  modeling  and  simulation  design  principles  is  to  de-couple  the  vehicle  dynamics  model  from 
the  sensor  and  environment  models.  By  passing  information  over  a  global  shared  memory,  these 
models  do  not  directly  interact  with  each  other.  As  a  result,  it  is  inherently  flexible  to  exchange 
different  vehicle  geometries,  sensor  suites  and  waves  characteristics,  and  this  provides  a  basis  for 
simulating  the  low-level  motion  responses  for  a  range  of  existing  vehicles.  In  our  hardware  in  the  loop 
(HIL)  simulation,  actual  vehicle  software  runs  on  a  PC  104  486  platform  with  a  QNX  4.23  operating 
system,  whereas  the  simulator  runs  on  another  PC  platform  with  a  RedHat  6.1  Linux  operating  system. 
The  simulator  generates  the  relevant  sensor  data,  and  sends  them  to  the  vehicle,  and  it  replies  to  the 
simulator  with  a  set  of  actuator  commands  (fins  and  prop). 
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To  establish  an  HIL  simulation,  a  bi-directional  connection  must  be  established  between  two 
computers.  We  have  chosen  a  network  connection  based  on  TCP/IP  protocol  because  it  is  widely  used 
in  industry,  can  sustain  high-speed  data  transfer,  and  very  portable.  Although  this  protocol  is  not 
deterministic  and  network  traffic  could  introduce  unexpected  delays,  results  collected  thus  far  indicate 
that  with  our  cycle  rate  and  packet  size,  there  has  not  been  any  drop-out  even  the  platforms  are 
connected  to  a  LAN.  To  carry  this  further,  our  multi-Hardware-In-the-Loop  simulation  is  to  establish  a 
modeling  and  simulation  framework  for  multiple  AUV  cooperative  missions.  Multi-HIL  simulation 
involves  several  PCs  running  simulator  and  several  PC  104s  running  their  own  vehicle  software.  An 
important  difference  between  a  single  and  multiple  HIL  simulation  is  that  in  the  multiple  HIL 
simulation,  all  the  vehicles  need  to  have  their  environmental  information  synchronized.  In  addition  to 
that,  the  clocks  of  each  AUV  should  also  be  synchronized.  This  requirement  is  necessary  since  the 
validity  and  post-mission  verification  are  all  based  on  the  timestamps  from  the  individual  AUV  clocks. 

Environment  information  consists  of  waves,  currents,  LBL  reply  times,  and  bathymetry  although 
additional  information  can  be  included  in  the  future.  A  data  structure  that  encapsulates  all  these 
information  is  defined  which  is  then  translated  into  a  message  and  broadcasted  to  all  other  simulators 
over  the  network.  In  order  for  multiple  vehicles  to  cooperate  with  each  other,  a  vehicle  needs  to  know 
the  position,  attitude  and  speed  of  other  vehicles  during  a  mission.  Inter-vehicle  communication  is  thus 
an  important  attribute  for  multiple  HIL  simulation.  The  physical  and  data  layer  for  modem 
communication  is  currently  not  available. 

WORK  COMPLETED 

1.  High  Level  Control 

Controller  Design 

We  have  designed  a  generic  architecture  for  the  different  managers.  Each  manager  tailors  this  generic 
architecture  so  that  it  fulfills  its  specific  needs.  Most  of  the  objects  can  be  easily  identified  in  the 
CHASM  formalism. 

A  CHASM  consists  of  a  tree  structure  of  states,  with  one  or  several  root  states  at  the  top.  Actions  are 
associated  to  these  states.  An  entity  has  to  manage  this  set  of  states  and  to  trigger  the  transition  and  the 
different  actions  associated  to  the  states  in  the  current  active  path,  on  a  regular  basis.  The  CHASM 
manager  is  this  entity  and  is  responsible  of  initializing  the  CHASM,  managing  the  CHASM  tree,  and 
keeping  track  of  the  active  state  path.  Indeed,  a  CHASM  manager  has  to  run  the  CHASM  structure  at  a 
regular  frequency  to  ensure  the  good  execution  of  the  mission.  Consequently,  the  different  objects  of 
the  system  are  the  CHASM  manager,  the  parser  (or  Loader)  that  loads  the  CHASM,  the  actions,  the 
states,  the  transitions,  etc. 

State  Data  Structure 

It  is  much  more  convenient  to  generate  all  the  states  at  once,  and  then  to  transit  from  one  to  another. 
There  are  several  reasons  to  this: 

•  To  deal  with  a  Hierarchical  Finite  State  Machine,  not  just  one  state  is  active  at  any  one  time  but  a 
path  of  states.  A  check  of  the  transitions  of  the  state  with  a  higher  level  of  priority  is  done  first. 
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•  There  are  special  relations  between  the  states:  parent/child,  default  next,  default  child,  etc. 

•  Do  not  want  to  access  a  file  or  a  database  every  time  we  make  a  transition,  it’s  time  consuming.  All 
the  objects  are  loaded  at  init-time.  States  are  generated  by  the  Loader.  The  role  of  the  Loader  is  to 
parse  the  mission  plan  and  to  generate  all  the  objects  of  the  CHASM  architecture. 

Analysis  Class  Diagram 

The  CHASM  manager  manages  the  CHASM  data  structure  (a  forest  of  state  objects)  and  hence  acts  as 
a  container  for  the  different  states  of  the  system.  A  state  may  have  several  sub-states  to  allow  for  the 
hierarchy  property,  or  can  be  a  leaf  state.  Only  certain  states  are  active  in  the  CHASM  at  one  given 
moment.  They  belong  to  the  current  active  path,  which  starts  from  one  root  node  and  ends  with  a  leaf 
state.  Some  actions  are  associated  to  the  states,  and  they  are  run  as  long  as  the  system  is  in  this  state. 
There  are  different  types  of  actions  with  a  different  time  model,  so  all  the  actions  associated  to  the 
current  active  states  are  not  fired  every  time  the  CHASM  manager  is  fired.  Producer  represents  any 
entity  we  can  have  data  from,  mostly  sensors  or  payloads  (INS).  The  role  of  the  INS  is  to  merge  many 
sensor  data  and  to  synthesize  different  parameters  to  provide  the  position  and  the  speed  of  the  vehicle. 
This  is  done  at  the  low-level  in  our  system,  and  data  are  emitted  by  one  of  the  nodes  in  the  network. 
Consumer  represents  an  entity  we  can  send  data  to,  mostly  actuators,  but  also  low-level  controllers  that 
are  connected  to  the  network.  The  Actions  get  the  data  from  the  sensors,  from  the  INS  system,  or  from 
the  results  of  other  actions  and  do  some  processing,  before  publishing  the  results,  either  to  some 
consumers  or  to  other  actions.  The  class  diagram  allows  us  to  make  appear  the  ‘one  writer-many 
readers  rule’ . 

Transition  Design. 

Evaluating  a  transition  in  the  CHASM  formalism  is  done  in  two  states: 

Step  1  of  evaluating  whether  a  transition  should  be  made  consists  in  defining  some  test  Actions  and 
running  them.  They  define  some  criteria  and  test  some  variables  in  shared  memory  to  see  if  they  satisfy 
these  criteria.  The  Test  Action  objects  contain  the  extrinsic  data  for  the  test,  i.e.  the  criteria  value,  and 
the  tolerance  value,  and  the  Test  Action  Handler  is  the  object  that  performs  the  actual  test  and  knows 
how  to  access  shared  memory  to  do  it.  There  are  a  lot  of  different  criteria  that  can  be  tested:  pitch, 
altitude,  etc.  There  are  therefore  as  many  Test  Action  Handler  subclasses  as  there  are  criteria  that  can 
be  tested.  When  a  test  Action  is  triggered,  it  fires  the  associated  test  Action  Handler  passing  it  the 
parameters  for  the  test  and  this  one  performs  the  test.  The  result  is  Boolean  which  is  stored  in  the 
Action  Handler  object. 

Step  2  of  evaluating  whether  a  transition  should  be  made  is  to  evaluate  the  transition  condition.  The 
transition  condition  is  a  Boolean  expression  that  can  use  combinations  of  several  criteria.  The 
Transition  objects  of  our  system  must  have  a  mean  to  obtain  the  result  of  the  requirements  that  appear 
in  the  Transition  Condition.  They  must  have  a  reference  to  the  appropriate  Test  Action  Handlers.  This 
design  is  very  flexible  and  scalable  because  it  allows  de-coupling  functions  of  the  CHASM.  Transition 
conditions  can  be  composed  of  as  many  criteria  to  test  as  wanted. 
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2.  Simulation 


A  thread  called  environment  server  is  established  when  the  Multiple  HIL  simulation  starts.  Other 
simulator  that  joins  the  simulated  mission  later  will  create  a  thread  called  environment  client.  This 
client  connects  to  the  server  and  starts  receiving  data  from  it.  Each  simulator  has  its  own  configuration 
file  that  specifies  a  set  of  shared  memory  environment  variables  needed,  and  the  server  will  respond 
accordingly  to  fit  different  clients’  needs. 

Robustness  and  transparency  are  useful  design  attributes  for  the  Multiple  HIL  implementation.  These 
attributes  refer  to  the  stability  of  a  simulated  mission  when  one  or  several  simulators  fail  unexpectedly, 
and  the  flexibility  to  initiate  multiple  server/client  sessions.  As  a  result,  the  following  criteria  were 
established: 

•  An  HIL  simulation  joins  the  Multiple  HIL  simulation  as  a  client  first,  if  it  is  the  first  HIL 
simulation,  it  will  re-configure  itself  as  a  server. 

•  If  the  environment  server  terminates  unexpectedly,  another  client  will  automatically  change  itself 
to  a  server.  If  more  than  two  clients  remain,  the  client  with  the  highest  default  priority  will  become 
the  server.  This  priority  information  is  defined  in  the  configuration  file. 

During  a  simulation,  each  HIL  will  have  its  local  clock  or  time.  The  local  time  with  which  the 
environment  server  is  associated  is  also  called  the  global  time.  During  the  environment 
synchronization,  the  global  time  is  sent  to  all  the  clients  so  that  their  local  time  based  on  the  received 
global  time  can  be  updated.  This  is  how  the  clocks  in  multiple  HIL  simulation  are  synchronized. 
Currently,  the  environmental  information  synchronization  and  clock  synchronization  was 
implemented,  and  several  HIL  simulations  can  run  different  missions  in  the  same  environment 
simultaneously. 

RESULTS 

High  Level  Control 

The  CHASM  architecture  has  not  been  implemented  on  our  vehicles. 

Simulation 

The  multiple  HIL  simulation  has  been  implemented,  and  has  been  tested  with  multiple  clients  running 
on  separate  PCs.  The  robustness  of  the  client-server  architecture  was  demonstrated. 

IMPACT/APPLICATION 

This  project  will  foster  synergistic  development  of  advanced  mine  reconnaissance  operations  with 
multiple  vehicles  and  further  the  development  of  high  level  tactical  command  and  control. 
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TRANSITIONS 


None 

RELATED  PROJECTS 

•  Very  Shallow  Water  Mine  Reconnaissance  with  Multiple  AUVs 

•  Node-based  Adaptive  Sampling  and  Advanced  AUV  Capabilities 

•  Sampling  and  Survey  with  AUVs  in  Adverse  Weather  Conditions 
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